fix: match Spark's duplicate field and field id semantics in parquet field lookup by dwsmith1983 · Pull Request #5654 · apache/datafusion-comet

dwsmith1983 · 2026-09-03T03:42:48Z

Which issue does this PR close?

Closes #5801.

Part of the restructuring of #5365 requested in review: this extracts the duplicate field and field id matching semantics that previously traveled with the Delta contrib work, re-derived on top of the folding that #5602 added. It also absorbs the reader-factory validation that was stacked on it as #5808, since that commit cannot rebase onto main on its own and the two could not merge separately.

Rationale for this change

Four places where the native parquet field lookup diverges from Spark:

remap_physical_schema only shields id-bearing logical fields whose id is missing from the file. When a logical field's id matches one physical field but a stray physical column carries that logical field's name, the stray column can still name-match through the expression adapter fallback and hijack the read.
parquet_convert_struct_to_struct silently resolves a requested field id that matches more than one physical field to the first match. Spark raises the duplicate field error in field id lookup mode.
Case sensitive exact name lookup on duplicate names resolves to the first field, while Spark builds its name map with .toMap, where the last entry wins.
DataFusion's Parquet opener creates the physical expression adapter only when a predicate is pushed or the file schema differs from the requested schema. A file with no key-value metadata whose schema equals the requested schema, read with field id matching on and no data filter, skipped the validation above and read a struct with two children sharing a requested id positionally. Spark rejects that during schema clipping. Spark-written files always carry key-value metadata that arrow-rs folds into the file schema, so they always reach the adapter; the gap is metadata-free files.

What changes are included in this PR?

All id-bearing logical fields are shielded from name matching, the shield runs after the name match pass so a successful match claims the field first, and fake placeholder names skip a reserved set built from both schemas so they can never collide with real columns.
A requested field id resolving to more than one physical field raises SparkError::DuplicateFieldByFieldId (_LEGACY_ERROR_TEMP_2094). Duplicate ids that no requested field references remain harmless, at the root as well as inside nested types: the adapter records a root ambiguity per logical field and raises it from rewrite only for the columns a read references, the same way nested ambiguities are handled. Before this, a duplicate id on columns the read never asked for failed the query, while Spark answers it because clipParquetSchema only sees the requested schema.
Exact name lookup on duplicate names resolves to the last field.
The field mapping is resolved once per file in the adapter factory and reused for every batch; a mapping that reorders fields (ids resolved out of position) disables the metadata-only relabel shortcut, which would otherwise hand back the file's columns under the requested names with the values swapped.
The mapping resolver, the struct-holding type walk and the array converter now share one definition of which Arrow types are lists, so a List<Struct> read as a LargeList<Struct> (or any other pair of list representations) resolves its element fields with Spark's rules before Arrow changes the list layout. This is the same shape fix: apply Spark's Parquet conversion rules to nested struct/list/map fields #5681 takes for the converter, so whichever of the two lands second rebases mechanically.
The Parquet reader factory, which fetches every file's footer regardless of what the opener decides, gains an optional field id check installed at plan time only when field id matching is on and the requested schema carries a field id at any depth, so ordinary reads pay nothing. After the footer is fetched it converts the file schema to Arrow the way the opener does and resolves the requested fields with the same mapping resolver the adapter uses, raising the same errors. A per-file memo keyed on the cached footer's identity means a file is validated once per distinct footer, not once per batch.
The JNI error bridge walks the cause chain so a Spark error raised inside the reader factory keeps its Spark exception class instead of surfacing as a generic read failure. This is wider than the reader path: any typed SparkError reachable through a Context or Shared wrapper anywhere in the plan now keeps its class. An ANSI failure in a pushed-down filter is unaffected, because DataFusion stringifies it into an ArrowError::ComputeError and nothing typed survives the chain.

Both validation paths now validate the same scope, the columns a read requests. The footer check covers the required schema, and the adapter raises only for referenced columns. The check also catches a duplicate id on root fields and inside a list<struct> element, so it closes the same opener-skip gap for the root-level check, not only the nested one.

There is no equivalent gap for the case-insensitive duplicate name error: for the file and requested schemas to compare equal, the requested schema would have to hold two fields folding to the same name, and Spark rejects that at analysis with COLUMN_ALREADY_EXISTS. Two fields can share an id while having distinct names, which is what makes the duplicate id error reachable and the use_field_id && schema_holds_field_ids gate on the footer check sufficient.

How are these changes tested?

Rust, all written before the change they pin and failing on the previous head unless noted:

Adapter and conversion: stray column hijacking the remap, case insensitive sibling null-filled, duplicate id silently reading the first match, first-wins name resolution, swapped field ids bypassing the relabel shortcut, root duplicate id raised only for referenced columns (rewrite of an unreferenced column succeeds, of the ambiguous one errors).
List representations: a List<Struct> requested as LargeList<Struct> resolves to a non-positional element mapping, converts by id, and null-fills a requested element field the file lacks instead of reading its neighbour.
Scans through DataSourceExec on a file written without key-value metadata, asserting first that the file schema equals the requested schema so the opener skips the adapter: duplicate struct id rejected, unique ids read, check inert with field id matching off, the same through the planner's data schema plus projection wiring, duplicate id at the root, duplicate id inside a list<struct> element, case-insensitive duplicate name (_LEGACY_ERROR_TEMP_2093) rejected at footer load with the case-sensitive read of the same file succeeding, and unrequested root duplicate ids read through the adapter path.
JNI bridge: the chain walk finds a SparkError behind DataFusion's Context and External wrappers; a plain Parquet error still classifies as a file read failure.

Core crate 367 tests, bridge crate 32, clippy with -D warnings and fmt clean. Each commit compiles and passes the parquet module tests on its own.

Scala: a ParquetReadV1Suite case writes the file with parquet-mr and no key-value metadata, asserts the footer's key-value map is empty and that the plan carries the native scan, and expects Spark's duplicate field id error; it reported no exception against the previous native library. ParquetReadV1Suite, CometNativeReaderSuite and SparkErrorConverterSuite on Spark 3.5 against the rebuilt native library: 137 succeeded, 0 failed.

sunchao

This fixes stray-name matching and placeholder collisions, and adds nested duplicate-ID rejection and last-wins exact-name lookup. One gap remains: metadata-only struct relabeling bypasses the duplicate-ID check, as detailed inline.

I compared the code with maintained Spark 3.5 and 4.0 sources. Eight component-check groups passed using extracted Comet helpers with Arrow/Parquet 58.4.0 and DataFusion 54.1.0. A separate probe reproduced the cast bypass and verified a renamed-child control. These probes use limited scaffolding and are not full Comet scan, JNI or Spark query tests. The reported 246 native and 58 Spark 3.5 tests are the author's results.

At 04:51 UTC, current-head CI had 29 successful, 32 running and 7 skipped checks. Full CI validation was still pending.

sunchao · 2026-09-03T04:53:52Z

+                        // Mirror Spark's `foundDuplicateFieldInFieldIdLookupModeError`
+                        // (`_LEGACY_ERROR_TEMP_2094`): a requested ID resolving to more
+                        // than one file field is ambiguous.
+                        Some(indices) => {


[P2] Run duplicate-ID validation before metadata-only struct relabeling

Could you route metadata-only struct adaptations through this validation too? For file struct s<x: int id=1, y: int id=1, z: int id=2> and requested s<x: int id=1, y: int id=3, z: int id=2>, Spark rejects requested ID 1 as ambiguous. DataFusion emits a struct cast, but CometCastColumnExpr::evaluate takes types_differ_only_in_field_names and calls relabel_array, because that predicate ignores field-ID metadata. The new lookup never runs and leaves all three physical values in place. A focused probe using the current cast expression and a real Arrow/Parquet round trip returned [42, 43, 44], while renaming requested x made the same input reach the duplicate-ID error. Could you guard the relabel shortcut for ID-based reads and add a cast-expression or scan regression with unchanged child names?

Good catch, the shortcut sailed right past the new validation. Fixed in 3d68f22: the relabel arm is now guarded so that when use_field_id is set and the requested type carries field id metadata, evaluation falls through to the struct conversion where the duplicate id lookup runs. Chose the guard at the call site rather than inside types_differ_only_in_field_names since that predicate is a pure structural comparison with no access to the parquet options. Your exact probe is now a regression test (unchanged child names, duplicate id 1, asserts the 2094 error) plus a companion pinning that the fast path survives for name only differences without ids and for the flag alone.

sunchao · 2026-09-04T05:17:28Z

Reviewed head 58e67fee against base 55ae4f20. The PR is focused, but I found one new regression, an incomplete validation fix, and avoidable batch-processing overhead.

[P2] Placeholder collisions can suppress column defaults.
schema_adapter.rs:177 reserves exact names, while missing-column detection uses case-folded names. A generated __comet_unmatched_field_id_1 therefore collides with requested __COMET_UNMATCHED_FIELD_ID_1. In my reproduction, the base returns the configured default 7; this PR returns NULL.

Reserve names using the existing folded schema names. That change passed the reproduction. Constructing the reservation set only when shielding needs it would also avoid extra hashing on ordinary reads without field IDs.
[P2] Duplicate-ID validation still depends on whether a cast occurs.
The new guard in cast_column.rs:292 misses identical physical/requested schemas. Such reads can omit the cast entirely or return before the guard.

A real native Parquet scan of identical s<x: long id=1, y: long id=1> schemas returned [42, 43]; Spark 4.1.3’s schema-clipping check rejected the duplicate ID. This also occurs on the base, so it is an incomplete fix, not a new regression. Validation needs to cover reads that require no conversion.
Avoid allocating a vector for every unique ID on every struct conversion.
parquet_support.rs:270 changes the index to HashMap<i32, Vec<usize>>. An allocation probe using the old and new construction loops measured 8 → 264 allocations for 256 unique IDs.

A compact unique/duplicate entry would preserve the behavior. Collect matching field names only when reporting an ambiguity. The new contains_field_id_metadata predicate also depends on immutable expression state and can be computed once.

The strongest design improvement is to resolve and validate requested fields once per file schema, then reuse the mapping across batches. That addresses the validation bypasses and repeated lookup work together. Metadata-only relabeling remains safe when the resolved mapping is positional. A small mapping object is a useful abstraction here.

Validation: 100 native Parquet tests passed, with default HDFS features disabled. Additional head/base probes confirmed both correctness cases. Performance evidence measures component allocations, not overall scan speed. CI snapshot: 57 passed, 7 running, 7 skipped. Nothing was posted to GitHub.

dwsmith1983 · 2026-09-04T06:26:10Z

Thanks, all three are addressed in a69b5f5, following the once-per-file design you suggested.

The physical expression adapter factory already runs once per file schema, so it now resolves a small FieldMapping tree (struct sources, list and large list elements, map key and value, leaf) for every logical field that holds a struct, mirroring Spark's clipParquetSchema at each nesting level. Duplicate requested ids and ambiguous case-insensitive names are detected there, stored per logical field, and raised when the column is referenced, whether or not a cast is later emitted. The per-batch conversion receives the resolved mapping and applies it positionally, so there is no hashing or per-id allocation on the batch path; the index type is a compact entry that records an index and an ambiguity flag, and matching names are collected only when the error is built. The contains_field_id_metadata predicate is gone; the relabel shortcut is gated on the mapping being positional instead.

Your repros: the identical s<x: long id=1, y: long id=1> schema now raises the duplicate id error with no cast in the plan, pinned in Rust through the exec path and in ParquetReadV1Suite (the Scala case fails against the previous native library and passes now). The folded placeholder collision returns the configured default again, pinned in the adapter tests with Spark-style key-value metadata on the file.

One residual worth naming: DataFusion's opener skips the adapter entirely when the logical and physical schemas compare equal and no predicate exists. Spark-written files always carry key-value metadata that arrow-rs folds into the physical schema, so they always go through the adapter, but a file with no metadata at all and duplicated ids inside a struct would still read positionally. Happy to cover that in a follow-up if you think it matters.

dwsmith1983 · 2026-09-09T00:24:52Z

@sunchao the once-per-file mapping round covering your three findings is pushed. Ready for another look.

andygrove

convert_struct in native/core/src/parquet/parquet_support.rs around line 563 now calls array.column(from_index) with an index resolved at planning time against adapted_physical_schema, where the old code derived it from the runtime array's own DataType. The only guard is sources.len() != to_fields.len(), which checks the target side. What guarantees the struct array the reader hands back always carries the same children in the same order as the physical field the mapping was resolved against? If that can drift at all, this is an index panic in the executor rather than a DataFusionError. Checking from_index against array.num_columns() would bound the worst case.

The description lists last-wins exact-name resolution as one of the three fixes and resolve_struct_mapping does it for struct children. At the top level in case-sensitive mode with no field ids, needs_remap is false in schema_adapter.rs around line 520, so resolution falls to DefaultPhysicalExprAdapter, which goes through Schema::index_of and returns the first match. Spark builds caseSensitiveParquetFieldMap at the root message level with the same .toMap it uses for nested groups. Was the top level deliberately left out of scope?

The field-id ambiguity path is covered from several angles now. The case-insensitive name ambiguity that resolve_struct_mapping raises around line 388 does not appear to have a companion test in the new struct_field_matching module. It might be worth pinning that half too, since it is the branch that decides between an error and a silently wrong column.

On the residual you named where DataFusion skips the adapter when the two schemas compare equal and there is no predicate, I confirmed that short circuit in the 55.0.0 opener. Could you open a tracking issue and link it here so it does not get lost? The branch also conflicts with main right now and needs a rebase before anything meaningful runs against it.

dwsmith1983 · 2026-09-09T14:12:52Z

Rebased onto main and the three points are in the head (b438dce).

Bounds: convert_struct now looks the source index up with columns().get and returns an error naming the requested field, the index, and the child count instead of indexing; a test feeds a struct with fewer children than the mapping expects and asserts the error. A struct column arriving with a non-struct mapping errors the same way rather than passing through. I did not add a type-equality check there, since convert_array dispatches on the runtime child type and strict equality would reject coercions it handles.

Root last-wins: not deliberate, the top level had simply fallen to the default adapter. With duplicate exact names at the root in case-sensitive mode the remap path now runs, the shadowed earlier fields get a placeholder name so the default adapter's index_of lands on the last one, and the nested resolver does the same; Spark 3.5's clipParquetGroupFields uses one .toMap for root and nested groups. Tests at the adapter level and through DataSourceExec, plus one that a field id match still wins over the duplicate. One thing worth knowing: parquet-mr writes two root columns named d into a single column chunk keyed by path, so a Spark-written file with that shape reads six interleaved values in Spark and arrow-rs alike, and no Spark-comparable end-to-end assertion exists for it; the Rust scan test uses arrow-rs to write the file.

The case-insensitive ambiguity now has its companion test in struct_field_matching: A and a against a requested a errors naming both in case-insensitive mode and reads a in case-sensitive mode.

The opener short circuit is tracked in #5801.

…tead of picking the last

dwsmith1983 · 2026-09-15T10:17:24Z

Can we agree on that order and behavior? #5884 already tracks duplicate resolution; please explicitly track the field-ID gating gap and link both PRs.

The field-id gating gap is #5936, linked from both PRs. On behavior, this PR now does what Andy proposed on #5786 for the nested case rather than last-wins: a requested field that matches more than one byte-identical sibling is refused with a message naming the field, while reading the unique sibling beside them still works, both pinned in Rust and by a Scala read of a file whose struct carries dup, dup, other. Root exact duplicates read the first file column, as Spark's reader does, pinned end to end against Spark.

On order: since the refusal now lives in the resolver this PR owns, I would land this one first and rebase #5786 onto it for the shapes that remain, the metadata-time check included if it is still needed. The fallible name folding from #5845 is already propagated here.

sunchao · 2026-09-15T14:48:03Z

Reviewed head 1fa518b54 against base 1d0ce5fe8. One P2 regression remains.

P2: Footer validation rejects supported duplicate-root reads

parquet_support.rs:352 treats the root schema as a nested struct, applying the new duplicate-name rejection before the adapter can select the first root column.

Trigger: a file contains d, d, and a(id=7). Request d by name and a by ID, with case sensitivity and field-ID reads enabled.

Reader	Result
Spark 4.1.3 vectorized	`(1,100), (2,200), (3,300)`
Base native scan harness	Same rows
PR native scan harness	Duplicate-field error for `d`

Disabling field-ID reads makes the PR return the correct rows. The unrelated ID-bearing column activates the footer check and causes the failure.

Fix: preserve root first-wins behavior in footer validation while retaining nested rejection. Add a mixed ID/name regression through the reader factory.

Validation

120 component tests passed, plus Spark comparisons covering 32 read combinations.
Reviewed mapping, projection, array lifetimes, footer caching, and JNI errors. No other introduced actionable defects found.
Build limitation: the registry lacks DataFusion 55.1. Component probes used current sources with DataFusion 55.0 / Arrow 59.3; full Comet integration tests could not run.
CI: 7 passed, 12 queued/running, 9 skipped.

Full review and evidence (local review report and reproduction logs). Nothing posted to GitHub.

…semantics

…ing requested nested ones

dwsmith1983 · 2026-09-15T15:00:05Z

Fix: preserve root first-wins behavior in footer validation while retaining nested rejection. Add a mixed ID/name regression through the reader factory.

Done. validate_field_mapping now renames every later exact duplicate at the root to a name no request can match, keeping its type and metadata, before resolving, so the footer check binds the first root column the way the adapter does while a requested nested duplicate is still refused. Two regressions: a unit test on the check itself with d, d, a(id=7) requested by name and by id under case sensitivity and field ids (passes), the same under case-insensitivity (Spark's ambiguity error) and the nested shape (refused); and a reader-factory test that writes that file, loads its footer and runs FieldIdCheck.validate on it. Both fail without the change. Merged with main at a8e8157 first.

ErikBPF · 2026-09-16T03:07:27Z

Agreed on landing this first, then integrating the remaining nested-only checks in #5786. The separate mixed-type root investigation in #5964 now has parquet-java PR apache/parquet-java#3796. Spark descriptor/filter changes have passed targeted experimental checks, but still need upstream JIRA tracking, a current-master port and an available parquet dependency. That work remains separate from these Comet PRs.

comphead

The solution might be overcomplicated here. I would expect a small check, that checks all the plan nodes and related schema and if the struct found with duplicated name, then fallback

comphead

Let me try to come up with more light weight solution

andygrove · 2026-09-17T19:05:31Z

Triage note: #5786 is working the other side of duplicate Parquet field names in the native scan. It rejects ambiguous sibling names before the decoder is built, closing #5783, and explicitly leaves "Spark-compatible duplicate-name resolution" as separate work — which is this PR. You share parquet_exec.rs, schema_adapter.rs and eager_page_index_reader_factory.rs.

The risk is that the two disagree on the outcome for the same file: this PR resolves case-sensitive duplicates last-wins the way Spark's .toMap does, while #5786 would reject some of those reads before the lookup ever runs. Could you and @ErikBPF work out which cases each of you is claiming, and in what order they land?

ErikBPF · 2026-09-17T19:22:34Z

@dwsmith1983 yours have a lot more work implemented. I see no problem in landing it first and I adapt mine after. @andygrove when do you intent to close 1.1.0? Just want to know the feasibility to have both on this release

andygrove · 2026-09-17T19:23:53Z

@dwsmith1983 yours have a lot more work implemented. I see no problem in landing it first and I adapt mine after. @andygrove when do you intent to close 1.1.0? Just want to know the feasibility to have both on this release

There is no hard deadline, but I was hoping to have 1.1.0 released before the end of the month.

…eader tests Main now declines any requested schema that repeats a Parquet field id at planning time, so the two tests that asked for both id-1 fields no longer reached the native scan. Each now requests only one of them, keeps the scan native, and still expects Spark's duplicate field error from the reader.

dwsmith1983 · 2026-09-18T14:29:05Z

Could you and @ErikBPF work out which cases each of you is claiming, and in what order they land?

Order as ErikBPF said above: this PR first, #5786 adapts after. On the split: #6004 now declines at planning any requested schema that repeats an id, so I have dropped the equal-schema rationale from the tests here and they request a single id that the file carries twice. What this PR still adds is native raising Spark's error when a requested id is ambiguous in the file, last-wins exact-name lookup like Spark's .toMap, the id shield against a stray same-name column, one list-type definition across the mapping paths, and typed Spark errors surviving the JNI cause chain. #5786 claims byte-identical duplicate names that the decoder cannot represent.

I would expect a small check, that checks all the plan nodes and related schema and if the struct found with duplicated name, then fallback

That check is what #6004 landed for field ids, and it stays. The reader-side error covers the case a plan-level check cannot see, an id the requested schema names once that the file carries twice. If you would rather keep one mechanism, I can trim the footer check to that file-side case; the adapter path has to stay for the Spark error text.

comphead · 2026-09-18T15:25:20Z

Thanks @dwsmith1983 @ErikBPF, folks, WDYT to proceed with #5786 to patch physical scans and then check what cases are still not addressed in this field and fix pursue them in this PR?

The initial reason I was slightly concerned is 2k LOC to patch an extreme scenario

dwsmith1983 · 2026-09-18T15:34:14Z

Thanks @dwsmith1983 @ErikBPF, folks, WDYT to proceed with #5786 to patch physical scans and then check what cases are still not addressed in this field and fix pursue them in this PR?

The initial reason I was slightly concerned is 2k LOC to patch an extreme scenario

We can cut it down. The footer check's reason to exist went away with #6004, so I can drop it and its tests, which takes out the reader-factory and the Rust test bulk. What stays is the adapter raising Spark's error for an ambiguous requested id, last-wins exact names, the id shield and typed errors through the JNI cause chain, none of which #5786 covers. On order, #5786 currently does not type-check against main per @sunchao and would reject the DataFusion-written file you showed on #6004, so I would still land this first and let #5786 rebase onto the smaller diff. Does that work?

dwsmith1983 mentioned this pull request Sep 3, 2026

feat: add native Delta Lake scan contrib module (page/row-group pruning) #5365

Open

sunchao reviewed Sep 3, 2026

View reviewed changes

dwsmith1983 force-pushed the fix/parquet-field-id-semantics branch from 3d68f22 to e1d9eb3 Compare September 3, 2026 09:37

dwsmith1983 requested a review from sunchao September 3, 2026 09:40

dwsmith1983 force-pushed the fix/parquet-field-id-semantics branch from e1d9eb3 to 58e67fe Compare September 4, 2026 03:24

dwsmith1983 force-pushed the fix/parquet-field-id-semantics branch 7 times, most recently from 96aa08d to cc2ffa1 Compare September 6, 2026 12:36

andygrove added bug Something isn't working correctness area:scan Parquet scan / data reading labels Sep 6, 2026

dwsmith1983 force-pushed the fix/parquet-field-id-semantics branch 9 times, most recently from 4dba460 to 13c4afc Compare September 9, 2026 00:01

andygrove reviewed Sep 9, 2026

View reviewed changes

dwsmith1983 mentioned this pull request Sep 9, 2026

Duplicate field ids inside a struct are not validated when the file schema equals the requested schema and no predicate is pushed #5801

Closed

fix: refuse a requested nested field with identical sibling names ins…

1fa518b

…tead of picking the last

dwsmith1983 added 2 commits September 15, 2026 21:54

Merge remote-tracking branch 'origin/main' into fix/parquet-field-id-…

960906b

…semantics

fix: keep root duplicates first-wins in the footer check while reject…

64fd2e8

…ing requested nested ones

erikbogado-nstech mentioned this pull request Sep 15, 2026

Investigate mixed-type duplicate Parquet roots: Spark field-ID reads return anomalous values #5964

Open

Merge branch 'main' into fix/parquet-field-id-semantics

5a5760a

dwsmith1983 added 3 commits September 16, 2026 18:31

Merge branch 'main' into fix/parquet-field-id-semantics

cb3856c

Merge branch 'main' into fix/parquet-field-id-semantics

ae3adb8

Merge branch 'main' into fix/parquet-field-id-semantics

e66aa8a

comphead reviewed Sep 17, 2026

View reviewed changes

comphead requested changes Sep 17, 2026

View reviewed changes

comphead mentioned this pull request Sep 17, 2026

fix: fall back when a struct repeats a Parquet field id #6004

Merged

dwsmith1983 added 3 commits September 18, 2026 06:55

Merge branch 'main' into fix/parquet-field-id-semantics

235ff5b

Merge branch 'main' into fix/parquet-field-id-semantics

c475b81

dwsmith1983 requested review from andygrove and comphead September 18, 2026 14:43

Merge branch 'main' into fix/parquet-field-id-semantics

e082694

andygrove added this to the 1.1.0 milestone Sep 18, 2026

dwsmith1983 added 2 commits September 19, 2026 14:52

Merge branch 'main' into fix/parquet-field-id-semantics

9380f34

Merge branch 'main' into fix/parquet-field-id-semantics

0cc3bf8

Conversation

dwsmith1983 commented Sep 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

How are these changes tested?

Uh oh!

sunchao left a comment

Choose a reason for hiding this comment

Uh oh!

sunchao Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

dwsmith1983 Sep 3, 2026

Choose a reason for hiding this comment

Uh oh!

sunchao commented Sep 4, 2026

Uh oh!

dwsmith1983 commented Sep 4, 2026

Uh oh!

dwsmith1983 commented Sep 9, 2026

Uh oh!

andygrove left a comment

Choose a reason for hiding this comment

Uh oh!

dwsmith1983 commented Sep 9, 2026

Uh oh!

dwsmith1983 commented Sep 15, 2026

Uh oh!

sunchao commented Sep 15, 2026

P2: Footer validation rejects supported duplicate-root reads

Validation

Uh oh!

dwsmith1983 commented Sep 15, 2026

Uh oh!

ErikBPF commented Sep 16, 2026

Uh oh!

comphead left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

comphead left a comment

Choose a reason for hiding this comment

Uh oh!

andygrove commented Sep 17, 2026

Uh oh!

ErikBPF commented Sep 17, 2026

Uh oh!

andygrove commented Sep 17, 2026

Uh oh!

dwsmith1983 commented Sep 18, 2026

Uh oh!

comphead commented Sep 18, 2026

Uh oh!

dwsmith1983 commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dwsmith1983 commented Sep 3, 2026 •

edited

Loading

comphead left a comment •

edited

Loading